Adding the option to save/or not QA-flagged events - #149

I tried this out with data from 434-1 (gse_20260227T150331.hdf5). When I include QA-flagged events I get an ARM of 9.9 +/- 0.1 deg. When excluding QA-flagged events, I get 9.58 +/- 0.11 deg. However this doesn't improve the ARM all the way to the value I was getting during the original unit level calibration, 9.19 +/- 0.13 deg (which was done on March 6th).

I also tried it on 434-2 data (gse_20260128T103501.hdf5). Again, the ARM I find when excluding QA-flagged events (9.77 +/- 0.16 deg) still doesn't get down to the older unit level calibration number (9.11 +/- 0.15 deg). I also tested a couple different slow thresholds to see if that could be playing a role. When I use a flat 20 keV cut, the ARM (excluding QA-flagged events) is 10.72 +/- 0.1 deg. When I use the actual per-strip calibration file (20260126_LBL_HP52434-2_slow_thresholds_avg.csv), I get a similar value of 10.32 +/- 0.13 deg. I'm not totally sure what to make of this since I would've expected the slow threshold to improve the ARM a bit.

Okay, thanks for checking. Let me see if I can track all of the QA and BD events that may have changed to understand why we're not recovering the same ARM with the QA filter.

Hmm, I'm seeing behavior that makes sense to me when looking at 358-3, including with the threshold file. @julianmgerber What Nuclearizer git commit were you using when you got the older unit level calibration numbers for the two detectors listed above?

I checked out the develop/em branch from March '26 (commit 8114b7c):
I get 7.7 +/- 0.3 degrees FWHM for the ARM fit of gse_20250709T113820.hdf when using the threshold file (vs the worse results listed above).

Then, checking out the this PR and keeping the QA events, I get 7.8 +/- 0.3 deg, aka consistent results with the analysis with the older commit. Excluding QA events get 7.1 +/- 0.3 degrees. Again, these both are using the threshold file, I'm ignoring NN strip hits, and I'm using your strip pairing algorithm.

For me, using a flat 20 keV threshold gives worse results than the file threshold (7.7 deg vs 7.1 deg). I think this is because cutting with 20 keV is quite a bit larger than the thresholds in the file, so we're missing information and therefore getting worse reconstruction for some events (the spectrum shows a large low-energy tail with the 20 keV threshold). When you say you're expecting the slow thresholds to improve the ARM, do you mean you expected a better improvement with the file, or you expected a better improvement with the 20 keV cut?

@ckierans I'll try running it for 358-3 as well and see if I get the same numbers just to make sure I'm not doing anything wrong. For the original 434-1 unit level calibration, I believe I was on commit 3dd7d93. For 434-2, I originally ran it on a branch that had the updated strip pairing but was otherwise a bit behind develop/em. Essentially, I believe it was commit 2cd0898 with 8eb29cd cherry-picked.

For me, using a flat 20 keV threshold gives worse results than the file threshold (7.7 deg vs 7.1 deg). I think this is because cutting with 20 keV is quite a bit larger than the thresholds in the file, so we're missing information and therefore getting worse reconstruction for some events (the spectrum shows a large low-energy tail with the 20 keV threshold). When you say you're expecting the slow thresholds to improve the ARM, do you mean you expected a better improvement with the file, or you expected a better improvement with the 20 keV cut?

I think I expected the ARM to improve with the threshold cut file compared to no threshold cut. But the ARM I'm getting with the threshold cut file (10.32 deg) is worse than with no threshold cut at all (9.77 deg)

@julianmgerber I think we should merge this PR and make an issue for the ARM changes. This code does what it should (at least I think so), but the ARM changes are probably a larger issue we need to track down.

Note that as of right now, we are NOT filtering out events that have strip hits removed below threshold. Those are still included with a QA flag in the final evta file, even when we don't intend to save QA events (and maybe this explains the disagreement with your expectations of the threshold improving the ARM?). I could be persuaded to change this behavior, but it seems like we don't want to just remove events that have a strip hit below threshold with the QA filter.

@julianmgerber and I discussed on slack and we now believe there is no inconsistency in the ARM measurements from previous analysis.

I did a deep dive into the ARM results last Friday. And I’m sorry to say that my 7.7 degrees that I quoted for 358-3 above was a lie. I had accidentally loaded a default mimrec configuration that enforced a 90 deg scatting angle cut and gave me better results! It took me awhile to track that down.

I ACTUALLY get 8.5 +/- 0.3 degrees for 358-3 (gse_20250709T113820.hdf) with the current qa_options branch, the threshold file, and filtering out qa-flagged events. So what I’m getting is consistent with Julian. And without filtering the qa-flagged events, I get 9.16+/-0.24 degrees. Filtering out any event with a strip hit > then the threshold, when using the threshold file, gets me 7.9+/-0.3 degrees.

I also re-checked the my results using the March commit
8114b7c, and reanalyzed to get 8.9 +/- 0.22 degrees, which I believe should be consistent with the 9.16 +/- 0.24 degrees above when we couldn’t yet filter out qa-flagged hits.